This application relates generally to object-oriented computer programs and systems. In particular, the aspects of the invention are related to object spaces.
An object space may be implemented as an instance of a server to which participant programs connect as clients. Object spaces are the object-oriented incarnation of tuple spaces, which are well-known in the art of computer science. For example, in “Generative Communications in Linda”, which is incorporated herein by reference, David Glernter describes tuple spaces. KLAIM (Kernel Language for Agents Interaction and Mobility), an extension of Linda for supporting mobile processes, is incorporated herein by reference. Lime (Linda In a Mobile Environment) is another extension of Linda, for distributed and mobile environments, that is incorporated herein by reference. In “Using Agent Wills to Provide Fault-tolerance in Distributed Shared Memory Systems”, which is incorporated herein by reference, Antony Rowstron explains how to provide an “agent will” for an object. If a client program terminates abnormally, the agent will helps “clean up” the tuple space to remove any information that is not consistent with the fact that the client program is no longer reachable. With each of these prior art techniques, objects are not part of the tuple space. For example, agent wills cannot be affected by operations on the object space issued by other client programs.
Object spaces provide a way for multiple networked entities to coordinate their actions by writing objects to a shared space and querying this space for objects. FIG. 1A depicts a prior art system 10 that includes computers 12, 14, 16, and 18, coupled to one another across a WAN 20. The computers 12, 14, 16, and 18 respectively include client programs 22, 24, 26, and 28. The computer 14, for example, may include a server 30 with an object space 40. The client programs 22, 24, 26, 28 may perform operations on the object space 40 (across the WAN 20, in the case of the client programs 22, 26, and 28).
FIG. 1B depicts an alternative conceptual view of the system 10, in which the object space 40 is shown in more detail. The client programs 22, 24, 26, and 28 can write objects to the object space 40. For example, in FIG. 1B, the client programs are depicted as respectively writing objects 42, 44, 46, and 48. It may be possible for a client program (e.g., client program 24) to read an object (e.g., object 46) that has been written by another client program (e.g., client program 26). A client program (e.g., client program 28) may be able to issue a notify operation to a board 50 and receive event notifications, such as notifications of when an object has been operated upon (e.g., read or write). In addition, a client program may be able to delete (sometimes called “take”) an object (not shown).
Object spaces have been found to be inefficient because operations performed on the object space have to go through a network (or between operating system processes). Another problem with object spaces is that they result in unnecessary coupling because participants need to stay connected to the object space (or risk losing information). This problem is particularly troublesome in mobile computing where devices with transient connectivity to the network. Another problem with object spaces is that they are inflexible because it is not possible to add functionalities beyond the set of base primitives. Another problem with object spaces is that they introduce a rigid separation between the object space itself and the client programs connected to the object space, which results in problems of efficiency and scalability, and puts constraints on clients.
The cost of using an object space becomes prohibitive for distributed tasks that contain a large number of object space operations, or for situations with a large amount of objects on the object space or a large number of clients connected to the object space (at least partly because notify operations do not scale).